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Abstract 


The  Information  Systems  Survivability  Assessment  aSSA)  is  a  process  of  analytical  steps, 
which  the  Survivability/Lethality  Analysis  Directorate  (SLAD)  of  the  U.S.  Army  Rese^ch 
Laboratory  (ARL)  applies  to  networked  automated  Information  Systems  (INFOSYS)  of  military 

interest.  . 

The  goal  of  SLAD's  information  systems  survivability  (ISS)  tools,  techniques,  and 

methodology  (TTM)  development  program  is  to  generate  predictive  computer  models  that 
predict,  as  closely  as  is  reasonably  possible,  the  real-world  observed  behavior  of  specific 
information  processor  properties  caused  by  various  real-world  stimuli  using  an  agreed-upon  set 
of  metrics.  These  stimuli  range  from  normal  network  operations  to  the  stressing  stimuli  caused 
by  various  software  errors,  hardware  errors,  and  the  multitude  of  the  different  forms  of 
intentional  or  unintentional  misuse  and  hostile  attacks  to  which  an  information  processor  may 

be  subjected.  ,  j  r  • 

This  report  relates  the  specifics  of  an  analytical  model  that  has  been  developed  for  use  in 

ISSAs.  This  model,  the  Information  Systems  Survivability  Assessment  Model  (ISSAM),  was 
designed  to  be  used  in  modeling  the  sequence  of  events  and  the  response  of  the  information 
systems  to  different  information  operations  (lO)  threats  or  challenges. 
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1.  Background 


The  Open  Systems  Interconnection  (OSI)  reference  model  is  a  candidate  for  an  abstract  model 
to  guide  survivability  assessments.  The  OSI  model  was  developed  as  the  first  step  toward 
international  standardization  of  various  protocols  and  is  the  accepted  standard  for  these 
developments.  The  OSI  model,  as  currently  configured,  is  not  suited  for  use  as  a  guide  for 
survivability  assessments  due  to  its  complexity  and  variance  fromreal-world  configurations.  The  OSI 
model  breaks  the  system  architecture  in  multiple  layers  (seven  to  be  exact),  but  the  model  does  not 
specify  the  exact  services  and  protocols  to  be  found  in  each  layer.  It  tells  what  each  layer  should  do. 
In  the  con:q)Uting  community,  opinions  concerning  the  OSI  model  vary  from  individual  to  individual. 
For  example,  according  to  Garfinkel  and  Spafford  [1]: 

The  OSI  model  is  a  classic  example  of  what  happens  when  a  committee  is  asked  to 
develop  complex  specifications  without  the  benefit  of  first  developing  working  code. 

On  matters  such  as  data  transmission,  the  OSI  standards  have  in  general  proven  to 
be  too  cumbersome  and  complex  to  fully  implement  efficiently. 


This  model  is  too  abstract  for  use  as  a  guide  for  Information  Systems  Survivability  Assessments 
(ISSA);  therefore,  another  model  is  needed.  For  further  details  on  the  OSI  model,  see  Tanenbaum 

[2]. 


Setting  aside  its  overt  con^lexity  raised  by  Garfinkel  and  Spafford  [  1  ] ,  the  OSI  architecture  could 
be  used  for  the  development  of  protocols,  specific  to  OSI.  This  model,  therefore,  would  be  best 
suited  for  performing  survivability  assessments  on  systems  using  OSI  protocols.  In  this  same  vam, 
using  the  Transmission  Control  Protocol  (TCP)/Intemet  Protocol  (IP)  architecture  would  be  best 
suited  for  survivability  assessments  where  only  TCP/IP  protocols  are  involved.  To  allow  for  an 
unbiased  survivability  assessment,  a  model  of  an  information  system,  independent  of  any  underlying 
architecture,  is  required. 
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2.  Purpose 


In  order  to  perform  ISSAs  for  a  multitude  of  different  systems,  a  model  of  the  information  system 
environment  is  required  to  place  the  analyses  into  a  common  framework.  The  genesis  of  this  report 
can  be  found  in  Table  2.2  on  page  28  of  Neumann  [3]:  ^RequirementsIDependence  Analysis  and 
Identification  of  Systemic  Inadequacies  for  Survivable  Systems  and  Networks.”  This  work  is  being 
performed  under  SRI  Project  1688,  Contract  DAKF11-97-C0020  for  the  U.S.  Army  Research 
Laboratory  (ARL).  The  scheduled  completion  date  is  25  September  1998.  The  contract  monitor  is 
Mr.  Anthony  Barnes,  ARL,  Survivability/Lethality  Analysis  Directorate  (SLAD)/Information 
Operations  (10)  and  C4I  Branch,  <bamesa@doim6.monmouth.army.mil>. 

The  purpose  of  this  report  is  to  relate  the  specifics  of  an  analytical  model  developed  for  use  in 
ISSA.  This  model,  the  Information  Systems  Survivability  Assessment  Model  (ISSAM),  was  designed 
to  be  used  in  modeling  the  sequence  of  events  and  the  response  of  the  information  systems  to 
different  10  threats  or  challenges.  This  ISSAM  is  to  become  a  major  analytical  tool  for  use  in 

SLAB’S  ISSAs. 

3.  Description 

In  the  context  of  an  ISSA,  an  information  system  is  defined  by  Joint  Pub  6-0  [4],  as: 

The  entire  infrastructure,  organization,  personnel,  and  components  that  collect, 
process,  store,  transmit,  display,  disseminate,  and  act  on  information. 

This  definition  covers  everything  from  a  single  networked  conputer  up  to  a  system  of  systems,  as 
well  as  everything  in  between. 
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The  ISSAM  being  presented  here  is  broken  into  eight  layers,  one  more  than  the  OSI  model.  The 
layers  here  are  meant  to  be  much  less  abstract  than  the  OSI  layers  and  can  be  directly  related  to  real 
information  systems  configurations.  Table  1  shows  the  layers  of  the  ISSAM. 


Table  1.  Layers  of  the  ISSAM 


User 

Application 

Middleware 

Operating  System 

Hardware 

Networking 

Inside  Environment 

E 

Outside  Environment 

_ 

The  layers  are  presented  from  the  perspective  of  the  normal  user,  that  is  to  say,  from  the  inside 
out.  As  one  progresses  down  through  the  layers  in  the  stack,  the  complexity  of  each  layer  grows  with 
respect  to  the  previous.  As  the  number  of  components  in  a  layer  grows,  so  does  the  complexity  of 
the  layer.  This  model  could  also  be  depicted  as  eight  concentric  circles  with  the  user  as  the  inner¬ 
most  circle  and  the  outer-most  circle  being  that  of  the  outside  environment.  Rendered  in  this  way, 
the  complexity  of  the  layers,  as  well  as  their  scope,  can  be  seen  to  increase  as  one  progresses  out  from 
the  center.  The  area  covered  by  each  of  the  concentric  circles  can  be  viewed  as  being  proportional 
to  the  conq)lexity  of  a  given  layer. 

The  flexibility,  which  is  gained  by  the  ability  to  depict  this  model  differently  for  different 
situations,  is  of  great  benefit  to  the  ISSA  process.  Depending  upon  the  system  being  assessed,  the 
analyst  has  the  capability  to  depict  the  system  in  various  ways.  The  number  and  type  of  systems  that 
can  be  assessed  is  increased.  Granularity  for  each  assessment  is  driven  by  the  requirements  of  the 
individual  assessment.  The  picture  of  the  system  can  be  different  when  the  assessment  is  being  done 
on  an  individual  item  or  a  system  of  systems.  An  assessment  being  done  on  an  individual  item  (e.g.. 
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a  router,  switch,  firewall,  computer,  etc.)  begins  with  a  small  granularity.  When  the  assessment  is 
being  done  on  a  set  of  networked  devices  that  are  in  the  same  room,  building,  or  canqius  (a  local  area 
network),  the  granularity  is  greater  than  that  of  an  individual  item.  Finally,  when  the  assessment  is 
being  done  on  a  system  of  systems  (e.g.,  a  networked  collection  of  local  area  networks  creating  a 
wide  area  network),  the  granularity,  due  to  necessity,  is  much  larger  than  that  of  a  local  area  network. 

Independent  of  the  granularity,  if  the  assessments  are  done  using  a  framework  of  the  survivability 
model,  presented  here,  the  processes  used  in  the  assessments  will  be  identical.  Whether  one  is  dealing 
with  a  system  of  systems  or  an  individual  item,  the  operating  system  interacts  with  the  hardware  in 
the  same  way.  It  is  also  trae  that  the  hardware  interfaces  with  the  networking  elements  consistently. 
These  facts  lend  themselves  to  the  application  of  a  consistent  methodology  to  be  used  in  these 
assessments.  When  using  this  ISSAM,  one  needs  to  be  mindful  of  the  definitions  of  the  individual 
layers  and  apply  them  consistently  when  depicting  the  system  Correct  and  consistent  use  of  the 
terminology  and  definitions  across  multiple  assessments  will  enable  the  information  produced  in  one 
assessment  to  be  directly  applicable  to  other  assessments  when  common  elements  are  found.  The 
definitions  of  the  eight  layers  are  presented  in  the  following  section. 

4.  Definitions 


The  eight  layers  are  defined  as  follows: 

4.1  User.  A  user  is  any  entity  that  uses  system  resources.  At  any  given  time,  a  user  can  be  a 
person  accessing  a  system  through  a  keyboard  at  either  the  desktop  workstation  or  the  server 
consoles.  Console  access  is  rare  for  the  average  user.  Normally,  server  consoles  are  secured  in  a 
computer  room  with  limited  access.  At  other  times,  a  user  may  be  a  process,  an  agent,  a  subsystem, 
or  any  conq)uter-related  entity.  The  specific  identification  of  an  entity  is  dependent,  upon  the 
particular  event  under  analysis. 
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4.2  Application.  Applications  run,  or  execute,  on  either  servers  or  desktop  workstations.  At 
this  level  of  the  ISSAM,  the  applications  have  no  dependency  upon  any  network  resources.  These 
applications  depend  only  upon  the  local  computing  platform  upon  which  they  are  executing. 

43  Middleware.  Middleware  is  a  class  of  application  that  requires  network  service  to  reach  full 
functionality.  This  is  a  class  of  applications,  either  distributed  or  network  dependent,  includes  web 
servers,  database  management  systems,  distributed  computing,  distributed  datamining,  and  data 
serving  to  distributed  machines,  etc. 

4.4  Operating  System.  The  operating  system  is  the  software  controlling  the  hardware  of  nearly 
all  types  of  networked  devices.  This  includes  servers,  desktop  workstations,  hubs,  routers,  firewalls, 
uninterruptable  power  supplies  (UPSs) ,  emergency  generators,  network  switches,  etc.  The  operating 
system  is  human  intelligible  hardware  independent  computer  languages  (e.g.,  C,  PASCAL,  COBAL, 
FORTRAN,  etc.)  compiled  (or  translated)  into  hardware  dependent  machine  language.  The  operating 
system  manages  the  interfaces  between  the  user,  application,  and  middleware  applications  and  the 
hardware. 

4.5  Hardware.  The  hardware  is  made  up  of  components,  subsystems,  and  systems.  A 
con5)onent  is  an  individual  item  such  as  an  integrated  circuit  (IC)  chip,  cable,  disk  platter,  cooling  fen 
blade,  printed  circuit  board,  etc.  A  subsystem  is  an  assemblage  of  components  or  subsystems.  For 
exan^le,  a  Hisk  drive  is  a  subsystem;  it  is  constructed  from  motors,  read/wnte  heads,  disk  platters, 
cables,  IC  chips,  printed  circuit  cards,  etc.  To  further  con5)licate  matters,  a  disk  drive  is  a  con^onent 
of  an  input/output  (I/O)  subsystem.  An  I/O  subsystem  is  made  up  of  disk  drives,  printed  circuit  cards, 
IC  chips,  cables,  data  buses,  etc.  A  system  is  a  collection  of  subsystems.  Exan^les  of  subsystems 
are  I/O,  graphics,  memory,  power,  etc. 

4.6  Networking.  A  network  is  a  collection  of  devices  that  communicate.  The  network  is  what 
links  the  users,  applications,  middleware  applications,  operating  systems,  and  hardware  together.  The 
devices  that  create  the  network  are  extremely  sophisticated,  and  aU  run  applications,  middleware 
applications,  and  operating  systems  to  control  their  hardware.  For  exan5)le,  network  routers. 
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switches,  and  hubs  are  hardware  that  is  controUed  by  operating  systems  running  applications  to 
manage  middleware  applications  in  order  to  create  a  network  upon  which  to  pass  information. 
Networking  mediums  currently  include  copper,  fiber  optics,  microwave,  radio  firequencies,  satellite 
communications,  etc.  Networks,  local  area  and  wide  area,  can  be  made  up  of  a  single,  multiple,  or 
all  types  of  mediums.  The  interfacing  of  different  mediums  is  handled  by  switches,  routers,  hubs,  etc. 


4.7  Environment.  The  environment  can  be  broken  into  two  pieces:  that  which  can  be 
controlled  and  that  which  cannot  be  controlled.  These  can  also  be  described  as  inside  (controllable) 
and  outside  (uncontrollable). 

4.7.1  Inside  Environment.  The  inside  environment  is  controllable.  For  exan^le,  the 
environment  in  a  computer  room,  an  office,  a  building,  or  a  c^pus.  All  types  of  sites,  permanent 
or  temporary,  have  requirements  for  power  and  network  coimections,  both  of  these  come  fi:om  the 
outside  environment.  Permanent  (or  fixed)  sites  may  have  emergency  generators  as  fallbacks  m  case 
of  loss  of  power  firomthe  outside  environment.  Ten5)orary  (or  mobile)  sites  generally  depend  upon 
internal  power  production,  either  firom  batteries  or  generators.  When  power  production  is  done 
within  a  site,  it  becomes  a  part  of  the  inside  environment;  in  this  case,  the  only  requirement  from  the 
outside  environment  becomes  the  network  connection.  The  inside  environment  may  also  contain 
power  conditioners;  this  includes  items  such  as  power  distribution  units,  generators,  uninterruptable 
power  supplies,  surge  suppressors,  etc.  All  of  these  items  are  controllable  even  if  they  rely  upon  the 
outside  environment  for  a  primary  power  feed. 

4.7.2  Outside  Environment.  The  external  feeds  for  network  connection  and  power  come  from 
the  outside  environment  to  the  inside  environment.  The  outside  environment  is  by  far  the  largest 
piece  of  the  environment.  This  is  the  worldly  environment,  to  include  terrestrial,  marine,  aerial, 
arboreal,  spatial,  etc.  In  this  environment,  events,  such  as  lighting,  floods,  other  weather  phenomena, 
earthquakes,  asteroids,  meteorites,  solar  flares,  etc.,  occur.  These  events,  also  termed  “acts  of  God,” 
are  uncontrollable  and  in  most  cases  unpredictable. 
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5.  Discussions 


A  generic  computing  environment  is  shown  in  Figure  1.  This  environment  is  depicting  a  generic 
wor]q)lace  type  of  setting  and  is  intended  to  be  a  generic  client/server  configuration,  as  well  as 
independent  environment  with  desktop  machines  capable  of  interacting  with  a  networked  compute 
server.  Also  note  that  the  environment  depicted  is  independent  of  the  operating  systems  and  specific 
computing  architectures. 
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Figure  1.  Computing  Environment. 
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Figure  1  is  also  broken  into  two  environments:  the  smaller,  controllable,  inside  environment  and 
the  much  larger,  uncontrollable,  outside  environment.  Feeds  for  both  the  network  connection  and 
power  feed  are  shown  crossing  from  one  environment  into  the  other.  The  network  connection  could 
be  either  a  physical  connection  made  with  some  type  of  cable  or  an  ether  type  of  connection  using 
radio  or  microwave  frequencies.  The  network  example  shown  in  Figure  1  is  totally  fictitious  and  was 
created  solely  for  illustrative  purposes. 

Each  of  the  devices  shown  in  Figure  1  can  be  represented  using  the  layers  from  Table  1.  The 
different  types  of  devices  are  represented  differently.  For  exan:ple,  the  desktop  workstations  are 
represented  by  the  user  through  the  inside  environment  layers,  with  dependencies  on  the  outside 
environment  (as  do  aU  networked  devices).  In  contrast  to  the  desktop  workstation,  the  emergency 
power  generator,  which  also  has  dependencies  upon  the  outside  environment,  can  be  represented  with 
a  much  smaUer  number  of  layers.  These  consist  of  the  application  (waiting  for  a  signal  through  the 
serial  connection),  the  operating  system  (which  manages  all  the  hardware),  the  hardware,  and  the 
inside  environment  layers.  It  can  also  be  seen  that  different  stimuli  are  represented  by  different  types 
of  interactions  of  the  model  layers.  One  place  where  these  interactions  are  detailed  is  in  the  item 
requirements  and  specifications  packages. 

Table  2  reproduces  Table  2.2  from  Neumann  [3].  This  table  shows  how  the  level  of  abstraction 
used  in  the  model  can  also  be  used  to  describe  possible  conpromise.  Garfinkel  and  Spafford  [1]  also 
present  a  detailed  discussion  of  this  table. 

With  the  structure  as  presented  in  Table  2,  con^romise  can  come  from  three  sources:  outside, 
within,  or  below.  Within  an  information  systems  survivability  framework,  conqjromise  is  used  as  a 
very  broad  term  rnpaniug  that  an  lO  on  information  warfare  (IW)  event  has  been  successful 
Neumann  characterizes  coii5)romise  from  the  three  sources  as  follows: 

•  Compromise  from  outside  typically  originates  from  an  access  point  that  is  nominally  external 
to  the  conqjonent  being  compromised. 
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•  Compromise  from  within  typically  originates  inside  a  particular  component  that  is 
compromised,  existing  at  a  given  level  of  abstraction. 

•  Compromise  from  below  is  initiated  at  a  lower  layer  of  abstraction  than  the  layer  at  which 
compromise  of  a  given  component  occurs. 

Given  the  data  from  Table  2  and  the  characterization  of  these  sources  of  con^romise,  it  becomes 
clear  that  a  system  may  be  inherently  compromisible  in  a  variety  of  ways.  The  goals  of  the  ISSA 
process  are  to  determine  the  ways  in  which  a  system  is  compromisible,  determine  the  likelihood  of 
occurrence  and  the  resulting  impact  on  the  system  due  to  these  coii^romises,  and  recommend  ways 
to  avoid  these  compromises.  A  systematic,  consistent,  and  correct  use  of  the  model  presented  here, 
as  well  as  a  common  methodology  used  in  the  ISSAs,  will  enable  con^rehensive  and  robust 
assessments  to  be  performed. 

6.  Summary 


The  abstract  computing  model  described  here,  shown  in  Table  3,  is  not  tied  to  any  particular 
protocol  family  or  to  any  one  system  architecture.  This  model  is  structured  robustly  enough  that 
multiple  machine  architectures,  as  well  as  different  protocol  femflies,  can  be  modeled.  The  model  is 
constructed  of  eight  separate  layers.  When  an  event  is  modeled,  the  appropriate  layers  are  traversed 
vertically  both  into  and  out  of  systems  as  required.  Events  are  modeled  by  the  interaction  of  the 
layers.  This  model  is  well  suited  to  vulnerability  assessments. 


7.  Conclusions 


A  model  of  a  real-world  confuting  environment  has  been  developed.  This  model  is  designed  for 
use  in  ISSAs.  This  model  is  of  hierarchical  construction  consisting  of  eight  layers.  These  layers 
progress  from  the  user  through  layers  associated  with  con^)Uting  machinery  and  networks  and  finally 
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Table  3.  Layers  of  the  ISSAMs 


User 


Application 


Middleware 


Operating  System 


Hardware 


Networking 


Inside  Environment 
Outside  Environment 


to  the  environment.  This  model  can  be  used  to  depict  machines  of  different  architectures  and  multiple 
networks  performing  a  variety  of  functions.  The  model  is  suitable  for  use  on  both  local  area  networks 
as  well  as  wide  area  networks  and  is  capable  of  incorporating  both  controllable  and  uncontrollable 
environmental  concerns.  The  flexibility  intrinsic  to  this  model  makes  it  comprehensive  enough  to 
model  permanent  (or  fixed)  installations,  transitory  (or  temporary),  as  weU  as  mobile  (or  dynamic), 
configurations.  In  military  parlance,  this  model  is  capable  of  modeling  the  global  information 
infi'astracture,  the  military  information  infi-astructure,  the  sustaining  base,  csmps,  posts,  stations,  and 
tactical  maneuvering  units.  These  can  be  modeled  independently  or  in  any  combination,  to  any 
desired  level  of  detail  (granularity)  required  for  the  particular  assessment. 

The  consistent  use  of  this  model  across  ISSAs  will  allow  for  tremendous  amounts  of  leveraging 
of  information  across  multiple  assessments  of  different  weapons  platforms  and  mihtary  systems.  The 
use  of  a  single  model  will  add  consistency  to  the  analysis  process. 
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